Nexbuild
Asplan Viak's construction consultancy team relied on Nexbuild. The brief said "redesign the interface." After my first week with the product, I quietly rewrote the brief: figure out what to remove, and prove it's safe to remove it.
The old system was built like an Office ribbon. Five tabs on top and around 25 buttons visible at all times. Four different views of the same project list. Eight "property" buttons for every project. A search field with two separate reset buttons next to it - which tells you a lot about how much people trusted that search.
Experienced users had simply learned to ignore most of the screen. New employees needed weeks to stop asking their colleagues where things were.
I flew to Norway and sat next to the people who actually use the tool. Site offices, hard hats in the corner, very strong coffee. Three things stayed with me:
- Experienced users don't read the interface - they remember it. They navigate by click paths built over years. Move things around carelessly and you break that.
- New people were lost for weeks. The ribbon gave no hint about what mattered.
- Many users were 45+, working in site offices with harsh daylight on their screens. Readability wasn't a "nice to have."
The entire interface was in Norwegian, and so was most of the conversation around it. It forced me to pay closer attention to how people actually interacted with the interface instead of relying on what they told me.
Before drawing anything, I put every single command from the old interface into a spreadsheet and asked: is this used daily, used inside a specific project, used rarely but critical, or just redundant?
Three destinations in the navigation - Assignments, Document search, Settings - and everything else moved into the context of a project.
- Four list views became one list. A single search field that checks five things at once, plus visible status chips and a favourites star.
- Eight global property buttons became tabs inside the project - overview, participants, documents, activity log.
- Location got promoted. People say "the Bergen job", not the project number. So place became a first-class field.
- Manual project numbers are gone. The number generates itself.
Every project's overview tab surfaces its construction schedule as a Gantt-style timeline alongside budget, milestones, and active risks - the numbers a project manager checks first, every morning.
Most projects are created by hand through a short guided wizard - basics, team, budget - with the project code generating itself. For teams migrating existing spreadsheets, a CSV import maps columns to system fields automatically and flags anything it can't resolve on its own.
Usage analytics flagged the improvement system - reporting of incidents, near-misses and suggestions - as basically dead. An obvious cut.
Then I talked to users. In Norwegian construction, HSE reporting is required by law. It's used rarely - thankfully - but when it's needed, it's not optional. Cutting it to make a toolbar look cleaner would have broken a legal process.
Instead of deleting it, I moved it: out of the global ribbon, into an HMS tab inside each project. A report always concerns a specific project anyway. Available exactly where it's needed, invisible everywhere else.
Everything about a project - general info, participants, documents, activity log, and HMS - lives inside one view with clear tabs. The high-contrast mode shows the same structure in a dark theme designed with equal care.
High-contrast mode and larger text sit one click away in the header of every screen, and the preference is saved in settings. I watched people squint at their screens in bright site offices. The dark high-contrast version is a complete theme, designed with the same care as the default - not a filter thrown on top.
Soft monochrome UI with a single pale-chartreuse accent, built for long shifts on dense operational data - the visual language the redesign runs on.
